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COMMON CHARGING IDENTIFIER 
FOR COMMUNICATION NETWORKS 

TECHNICAL FIELD 
The present invention relates to communication networks and, more 
particularly, the present invention relates to techniques for charging coordination and 
other kinds of information coordination, and a common charging identifier for 
communication networks. 

BACKGROUND ART 

In general, packet switched wireless networks provide communications for 
mobile terminals with no physical connection required for network access. The 
General Packet Radio Service (GPRS) in the Global System for Mobile 
Communications (GSM) and the Universal Mobile Terrestrial System (UMTS) have 
both been developed to provide wireless communications networks with a packet 
switched side, as well as a circuit switched side. 

The specifications for UMTS networks with further improvements have been 
released by the 3rd Generation Partnership Program (www . 3 gpp .org). Release 00 of 
the UMTS specifications provides that a network subscriber can have one or more 
packet data protocol (PDP) addresses. Each PDP address is described by one or more 
PDP contexts in the Mobile Terminal (MT), the Service GPRS Support Node 
(SGSN), and the Gateway GPRS Support Node (GGSN). The GGSN is a gateway to 
external networks. Each PDP context may have routing and mapping information for 
directing the transfer of data to and from its associated PDP address and a traffic flow 
template (TFT) for filtering the transferred data. 

Each PDP context can be selectively and independently activated, modified, 
and deactivated. The activation state of a PDP context indicates whether data transfer 
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is enabled for a corresponding PDP address and TFT. If all PDP contexts associated 
with the same PDP address are inactive or deactivated, all data transfer for that PDP 
address is disabled. All PDP contexts of a subscriber are associated with the same 
Mobility Management (MM) context for the International Mobile Subscriber Identity 
(IMSI) of that subscriber. Setting up a PDP context means setting up a 
communication channel. 

FIG. 1 is a process flow diagram that illustrates an example of the PDP context 
activation procedure. In step 100, the MT sends an Activate PDP Context Request to 
the SGSN. The Activate PDP Context Request message sent in step 100 includes a 
number of parameters. The parameters include a PDP address and an Access Point 
Name (APN). The PDP address is used to indicate whether a static PDP or dynamic 
PDP address is required. The APN is a logical name referring to the Gateway GPRS 
Support Node (GGSN) to be used. 

In step 1 02, the SGSN sends a Radio Access Bearer (RAB) setup message to 
the UMTS Terrestrial Radio Access Network (UTRAN) or the GERAN or other 
corresponding radio access networks . In step 104, the SGSN sends a Create PDP 
Context Request message to the affected GGSN. The GGSN decides whether to 
accept or reject the request. If it accepts the request, it modifies its PDP context table 
and returns a Create PDP Context Response message in step 106. The SGSN then 
sends an Activate PDP Context Accept message to the Mobile Terminal in step 108. 

In Release 00 of the Universal Mobile Telecommunications System 
specifications (UMTS), a new architecture with existing and new logical entities is 
introduced to support IP multimedia services including, e.g., IP telephony. SIP 
(Session Initiation Protocol) is used for call control. The caller allocates a Call Id, 
which is included in SIP messages. The Call Id uniquely identifies the call and is used 
by all call participants However, the use of the Call ID is complicated in the case of a 
mobile station (MS) comprised of mobile terminal (MT) and terminal equipment (TE) 
parts since the MT driver in the TE is preferably able to filter the UDP/IP packets 
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forwarded to the MT 5 and be able to parse the majority if not the entire SIP grammar 
to find the Call-ID field contained somewhere in a UDP datagram. 

The subscribers of voice services are accustomed to receiving bills based on 
calls, not based on the transport resources used for making the calls. Subscribers of IP 
telephony often expect similar billing criteria. Consequently, billing for the services 
used (e.g., for the calls) rather than the transport resources used is becoming 
increasingly important. In the case of Wireless Application Protocol (WAP) services, 
billing for services rather than transport resources is already the expectation. 

For an IP telephony call, a PDP context is required to carry the actual voice 
traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): the GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. A 
common identifier ought to be added to the CDRs to make it possible to bill based 
only on the CDRs created by the IP telephony layer (i.e., for services) and to omit the 
CDRs created by the GPRS/UMTS layer (i.e., for transport resources). 

A common identifier is needed in the CDRs created by the GPRS/UMTS layer 
and by the IP telephony layer to make it possible to omit certain CDRs and enable 
billing based on services rather than use of transport resources. More specifically, in 
many cases it would be advantageous to selectively omit CDRs created by the 
GPRS/UMTS layer or CDRs created by the IP telephony layer. If that were possible, 
the billing would be operator-specific, in that the operator could decide how to bill the 
subscribers (how to use the created CDRs). 

In spite of the numerous details provided in the aforementioned protocol, 
many features associated with mobile networks have not been dealt with. 
Specifically, charging information can be created by the SGSN, the GGSN and by the 
IP telephony network elements, e. g. the CSCF. At present there is no solution in 
place to associate the charging information created by the SGSN, the GGSN and the 
charging information created by the CSCF. Indeed, the network may be so 
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complicated (e.g., the charging data may be generated in many different network 
elements) that it is not possible to combine all call event related data. At least some 
of this data is needed in order to implement network functionality such as hot billing 
or merely to allow a network operator to implement joint billing for GPRS services 
and JP telephony services. 

DISCLOSURE OF THE INVENTION 
According to a first illustrative embodiment of the invention, when an 
Activate PDP Context Request message is forwarded to a Service GPRS Support 
Node (SGSN) by an MT, the SGSN creates a Create PDP Context Request message 
and forwards it to a Gateway GPRS Support Node (GGSN). In response to the Create 
PDP Context Request forwarded by the SGSN, the GGSN creates a Create PDP 
Context Response message. When a PDP context is created by the GGSN, the GGSN 
associates a Charging Identification parameter with the PDP context. Then, the Create 
PDP Context Response including the Charging Identification parameter is forwarded 
to the SGSN. In response to the PDP Context Response forwarded by the GGSN to 
the SGSN, the SGSN forwards an Activate PDP Context Accept message to the MT. 
According to the first embodiment of the invention, both the Charging Identification 
parameter and possibly the GGSN address are provided to the MT in the Activate 
PDP Context Accept message. As described herein, the mobile station (MS) includes 
two parts: the terminal equipment (TE) and the mobile terminal (MT). The MS may 
also be referred to as user equipment (UE). The TE can, e.g., be a laptop which is 
then connected to the MT. The MT can be a mobile phone. 

Sending the GGSN address is not mandatory. Another alternative is that the 
CSCF adds the IP address of the MS to the charging records (CDRs) that it creates for 
a call. The SGSN and the GGSN already add the PDP address of the PDP context to 
the CDRs. By checking that the PDP address is the same as the IP address, it can be 
ensured that the PDP context has been used for the call in question. Since this 
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requires that the charging identifications are the same, the CSCF adds the Charging 
Identification to the CDRs that it creates for the call in question. 

According to a second illustrative embodiment of the invention, the Charging 
Identification can be sent from the SGSN or the GGSN to the Call State Control 
Function (CSCF). When an Activate PDP Context Request message is forwarded to 
the SGSN, the SGSN creates a Create PDP Context Request message. The SGSN 
sends the Create PDP Context Request to the GGSN. In response to the Create PDP 
Context Request received from the SGSN, the GGSN creates a Create PDP Context 
Response. The GGSN associates the Charging Identification parameter with the PDP 
context. The Create PDP Context Response including the Charging Identification 
parameter is then forwarded to the SGSN. 

The Charging Identification parameter can be sent from either of the SGSN or 
the GGSN directly to the CSCF; and, such sending of the Charging Identification 
parameter can be performed either autonomously, e.g., at PDP context activation, or 
based on a request from the CSCF. 

In a specific embodiment, the CSCF sends the charging identification towards 
an endpoint of a communication, and sends security information together with said 
charging identification toward the endpoint. The CSCF is able to send an address of a 
GGSN together with the charging identification to the endpoint. If the GGSN address 
is not sent with the charging identification, the CSCF adds the IP address of the 
mobile station (UE) to the CDRs. 

In a variation of the first and second illustrative embodiments, the Charging 
Identification parameter is a Globally Unique Charging Identification (GC1). 
(Although referred to in this application as "globally" unique, the charging 
identification need only be utilized by as few as only two networks.) The GCI is used 
during a call to ease combination of call event related data from different network 
elements. One particular feature of the embodiment is that the GCI can be generated 
by any network element. It can be generated by the SGSN, GGSN or CSCF. Such a 
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network element can be a 2 nd generation network element or a 3 rd generation network 
element. In any event, the network elements (other than the network element which 
generated the GCI) do not need to generate a charging identification, but instead use 
the GCI generated by the other network element. The GCI can be used to ease 
combination of all call event related data or any portion thereof. As an example, the 
GCI and all the charging data for a call event can be collected and used by another 
network, such as one including a post-processing system providing billing for network 
subscribers. 

The principles of the invention are applicable to other types of communication 
channels in addition to PDP contexts. 

For an IP telephony call, a PDP context is required to carry the actual voice 
traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): The GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. 
According to a third illustrative embodiment of the invention, a common identifier is 
added to the CDRs, which, for example, makes it possible to bill based on the CDRs 
created by the IP telephony layer (i.e., for services) and omit the CDRs created by the 
GPRS/UMTS layer (i.e., for transport resources). 

According to the principles of the third embodiment of the invention, the 
common identifier is associated with the CDRs created by the GPRS/UMTS layer and 
by the IP telephony layer. The common identifier enables charging coordination and 
other kinds of information coordination. 

A call in SIP is identified by the Call Identification which is used as the 
common identifier. The Call Identification is allocated by the caller and included in 
the SIP messages. The MS sends the SIP messages to the called party via the CSCF. 
The CSCF intercepts the SIP messages and can thereby obtain the Call Identification 
from the SIP messages. 
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To use the Call Identification for charging coordination or other kinds of 
information coordination in accordance with the principles of the invention, the MS 
sends the Call Identification to the SGSN and the GGSN during PDP context 
activation. More specifically, the MS sends the Call Identification to the SGSN along 
with the Activate (Secondary) PDP Context Request message, and the SGSN forwards 
the Call Identification to the GGSN along with the Create PDP Context Request 
message. 

The process described herein works for both mobile-originated calls (where 
the MS allocates the Call Identification) and mobile-terminated calls (where the MS 
receives the Call Identification in the SIP Invite message). According to the process 
described herein, the SGSN and the GGSN add the Call Identification to the CDRs 
that they create for the PDP context, and the CSCF adds the Call Identification to the 
CDRs that it creates for the call. 

A fourth embodiment of the invention is similar to the third embodiment, 
except that a unique identifier is formed by using the UDP port number present in the 
SDP syntax of SIP "INVITE" and "1 83 Session Progress" messages instead of the 
Call-ID field. 

In either of these embodiments, an operator is given greater flexibility in 
deciding how to bill subscribers for the created CDRs. The operator can selectively 
omit billing for CDRs created by the GPRS/UMTS layer while choosing to bill for 
CDRs created by the IP telephony layer. 

Other aspects and advantages of the invention will become apparent from the 
following detailed description and accompanying drawings, illustrating by way of 
example the features of the invention. 

BRIEF DESCRIPTION OF THE DRAWINGS — 
The foregoing and a better understanding of the present invention will become 
apparent from the following detailed description of example embodiments and the 
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claims when read in connection with the accompanying drawings, all forming a part of 
the disclosure of this invention. While the foregoing and following written and 
illustrated disclosure focuses on disclosing example embodiments of the invention, it 
should be clearly understood that the same is by way of illustration and example only 
and the invention is not limited thereto. The spirit and scope of the present invention 
are limited only by the terms of the appended claims. 

FIG. 1 is a generalized process flow diagram illustrating the PDP context 
activation procedure. 

FIG. 2 is a generalized block diagram of the architecture of a packet switched 
wireless communication network in which the example embodiments of the invention 
can be practiced. 

FIG. 3 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with a first embodiment of the present invention. 

FIG. 4 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with an arrangement of a second embodiment of the 
present invention. 

FIG. 5 is a generalized process flow diagram illustrating sending a charging 
identification in accordance with another arrangement of the second embodiment of 
the invention. 

FIG. 6 is a generalized process flow diagram illustrating sending a call 
identification in accordance with a third embodiment of the invention. 

FIG. 7 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with an arrangement of the third 
embodiment of the invention. 

FIG. 8 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with another arrangement of the 
third embodiment of the invention. 

FIG. 9 is a generalized process flow diagram illustrating sending a tuple or 
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tuple pair in accordance with a fourth embodiment of the invention. 

FIG. 10 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with an arrangement of the third 
embodiment of the invention. 

FIG. 1 1 is a generalized signaling flow diagram illustrating coordination of the 
application layer and transport layer in accordance with another arrangement of the 
fourth embodiment of the invention. 

BEST MODE FOR CARRYING OUT THE INVENTION 
Before beginning a detailed description of the subject invention, mention of 
the following is in order, when appropriate, like reference numerals and characters 
may be used to designate identical, corresponding, or similar components in differing 
drawing figures. Furthermore, in the detailed description to follow, example 
sizes/models/values/ranges may be given, although the present invention is not limited 
thereto. 

An example of a network architecture supporting these specifications is the 
wireless communications network shown in the block diagram of FIG. 2. The various 
elements of the network and their functions are described in the General Packet Radio 
Service (GPRS) Service Description, Stage 2, 3GPP TS 23.060, published by the 3rd 
Generation Partnership Program ( www.3gpp.orgl The elements and their functions 
may be described in earlier or later versions of the 3GPP TS 23.060 specifications or 
may be those of any other known packet switched wireless communications network. 
The description of network elements and their functions are merely a non-limiting 
example of packet switched wireless communication networks. 

Several elements of the example network illustrated in FIG. 2 are particularly 
relevant to this invention. The Mobile Terminal (MT), commonly referred to as a cell 
phone or a mobile phone, is only one possible part of User Equipment (UE). 
Typically, Terminal Equipment (TE), used together with a Mobile Terminal (MT), 
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constitutes User Equipment (UE), which is also referred to as a Mobile Station (MS). 
Any UE may be utilized in conjunction with this invention so that it operates or can be 
programmed to operate in the manner described below. The UMTS Terrestrial Radio 
Access Network (UTRAN) and the Base Station System (BSS) in GPRS manage and 
control the radio access between the core network and a number of MTs. There are 
also other possible radio access networks like GERAN. 

The CSCF is a network element in an IP telephony network. The IP telephony 
network is sometimes referred to as "the application layer". The structure and 
function of the Call State Control Function (CSCF) can be divided into several logical 
components, which are currently internal to the CSCF. Every CSCF acting as a 
Serving CSCF has a Call Control Function (CCF) function. The CSCF includes an 
ICGW (Incoming call gateway). The ICGW acts as a first entry point. The ICGW 
performs routing of incoming calls. Incoming call service triggering (e.g. call 
screening /call forwarding unconditional) may need to reside for optimization 
purposes. The ICGW performs Query Address Handling (implies administrative 
dependency with other entities); and communicates with the Home Subscriber Server 
(HSS). 

The CCF (Call Control Function) performs call set-up/termination and 
state/event management; interacts with MRF in order to support multi-party and other 
services; reports call events for billing, auditing, intercept or other purposes; receives 
and process application layer registration; performs query address handling (implies 
administrative dependency); and may provide service trigger mechanisms (service 
capabilities features) towards application & services network (VHE/OSA). The CCF 
may invoke location based services relevant to the serving network, and may check 
whether the requested outgoing communication is allowed given the current 
subscription. 

The CSCF includes a SPD (Serving Profile Database). The SPD interacts with 
HSS in the home domain to receive profile information for the R00 all-IP network 
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user and may store them depending on the SLA with the home domain. The SPD 
notifies the home domain of initial user's access (which includes, e.g., CSCF 
signaling transport address, user ID, etc.) The SPD may cache access related 
information (e.g. terminal IP address(es) where the user may be reached, etc.) 

The CSCF performs AH (Address Handling) function. The AH function 
includes analysis, translation, modification, if required, address portability, and 
mapping of alias addresses. The AH function may do temporary address handling for 
inter-network routing. 

The Serving GPRS Support Node (SGSN) is the node that serves the MT. At 
PDP context activation, the SGSN establishes a PDP context used for routing 
purposes. The Gateway GPRS Support Node (GGSN) is the node accessed by the 
external packet data network due to evaluation of the PDP address. It contains routing 
information for attached GPRS/UMTS users. The routing information is used to 
tunnel Protocol Data Units (PDUs) to the SGSN. The SGSN and GGSN 
functionalities may reside in different physical nodes or may be combined in the same 
physical node, for example, the Internet GPRS Support Node (IGSN). 

The IP-based mobile network architecture includes an application layer and a 
transport layer. The transport layer protocols and mechanisms are usually optimized 
for the specific type of access whereas the application layer is normally generic, that is 
independent of the type of access. 

In IP-based mobile networks, the UE sets up a call by signaling to the peer 
entity and exchanging messages of a call control protocol over an IP connection 
provided by the transport layer. In setting up a call in the application layer, the 
underlying transport layer has to set up the transport bearers over the radio interface 
and in the transport network. For an IP-based mobile network, setting up of transport 
bearers means allocating radio resources and network resources. The call control 
signaling is transparently exchanged over an IP connection provided by the transport 
layer. 
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Embodiment 1 

FIG. 3 illustrates a process of sending a charging identification in accordance 
with a first embodiment of the present invention. In UMTS all-IP networks, when 
GPRS/UMTS is adopted as access/transport network for multimedia and voice over IP 
services, charging will be performed independently at the GPRS/UMTS layer and at 
the application layer (e.g., the CSCF). 

In the GPRS and UMTS networks, PDP contexts are created by the GGSN 
upon request from the SGSN (with a Create PDP Context Request message) that, in 
turn, receives the request from the MT (an Activate PDP Context Request message). 

As illustrated in FIG. 3, the technique in accordance with the present invention 
begins at the application layer at step 300 in which a trigger is forwarded from the TE 
(Terminal Equipment) to the MT (Mobile Terminal). The trigger may be, e.g., a call 
set up indication including the requested logical channels and characteristics, sent 
from the TE to the MT to start PDP context activation. 

At step 302, an Activate PDP Context Request message is forwarded to the 
SGSN. In response thereto, in step 304, the SGSN creates a Create PDP Context 
Request message and forwards it to the GGSN. In response to the Create PDP 
Context Request forwarded by the SGSN, in step 306, the GGSN creates a Create 
PDP Context Response message. 

In step 308, when a PDP context is created by the GGSN, the GGSN 
associates a Charging Identification parameter with the PDP context in step 308. 
Then, in step 3 1 0, the Create PDP Context Response message including the Charging 
Identification parameter is forwarded to the SGSN. 

In turn, in response to the PDP Context Response forwarded by the GGSN to 
the SGSN, in step 312, the SGSN forwards an Activate PDP Context Accept message 
to the MT. According to the first embodiment of the invention, both the Charging 
Identification parameter and the GGSN Address are provided to the MT in the 
Activate PDP Context Accept message. 
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The above noted procedures in steps 300-3 1 2 are repeated as many times as 
needed depending on the PDP contexts needed. 

Upon the completion of the last procedure in step 312, the UE forwards a call 
set up message, including requested logical channels and characteristics, to the CSCF 
(Call State Control Function) in step 3 1 4. The MT will, in turn, provide the Charging 
Identification and the GGSN Address to the CSCF within the call set up message. 
The CSCF, in turn, forwards the call set up message, including requested logical 
channels and characteristics, to the remote end point in step 316. The remote end 
point then forwards a response message, including accepted logical channels and 
characteristics, back to the CSCF in step 3 1 8. The CSCF then forwards the response 
message, including accepted logical channels and characteristics, to the UE in step 
320. The response message may be, e.g., the Connect message in H.323 or a SIP 
response message, but not necessarily limited to those. 

The invention contemplates that the Charging Identification parameter can be 
made more secure by applying appropriate cryptographic algorithms to avoid a false 
Charging Identification being forwarded by a malicious MT to the CSCF instead of 
the legitimate value, or a malicious MT re-using a value of the Charging 
Identification. 

From the foregoing, it will be appreciated that in the first embodiment of the 
invention, the Charging Identification parameter is sent from the SGSN to the UE and 
from the UE to the CSCF. 

Embodiment 2 

FIG. 4 illustrates a process of sending a charging identification in accordance 
with an arrangement of a second embodiment of the present invention. In UMTS all- 
IP networks, when GPRS/UMTS is adopted as the access/tran sport network for 
multimedia and voice over IP services, charging will be performed independently at 
the GPRS/UMTS layer and at the application layer (e.g., the CSCF). 



13 



WO 01/91446 



PCT/IB01/00890 



In the GPRS and UMTS networks, PDP contexts are created by the GGSN 
upon request from the SGSN (i.e., a Create PDP Context Request message) that, in 
turn, receives the request from the MT (i.e., an Activate PDP Context Request). 
According to the second embodiment of the invention, the Charging Identification 
parameter is sent from the SGSN or the GGSN to the CSCF. Unlike the first 
embodiment, there is no need to send the Charging Identification parameter via the 
UE. 

As described previously, in the first embodiment of the invention, the MT 
intercepts data packets that are sent from the TE and adds the Charging Identification 
parameter to a specific data packet ( the SIP message or the H.323 message for call set 
up). Interception of data packets may decrease the performance of the MT. 

In the second embodiment of the invention, the GPRS/UMTS and IPT 
network elements are able to coordinate charging information or other kinds of 
information, e.g., in order to combine charging information collected for a PDP 
context by the SGSN and the GGSN and for a call by the CSCF. Like the first 
embodiment, the GGSN allocates a Charging Id parameter at PDP context activation. 
And like the first embodiment, the GGSN sends the Charging Id parameter to the 
SGSN. But, unique to the second embodiment, the Charging Identification, possibly 
together with other information (e.g., IMSI, MS1SDN, PDP address, UE port number 
from the TFT, Charging Characteristics etc.) can be sent from the SGSN or the GGSN 
to the CSCF. 

Sending the Charging Id parameter can be performed either autonomously or 
based on a request from the CSCF. The SGSN will send the Charging Identification, 
since the address of the CSCF has to be known if something will be sent to it. The 
SGSN has an interface with the HSS (HLR+UMS), which contains the address of the 
serving CSCF. 

There also can be an interface between the GGSN and the CSCF. This new 
interface could then be used to carry the Charging Id and possibly other charging 
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related information. FIG. 4 illustrates an aspect of the second embodiment of the 
invention in which the SGSN sends the Charging-Id parameter to the CSCF. 

As illustrated in FIG. 4, a process of sending a charging identification in 
accordance with the present invention begins at step 400 in which a trigger is 
5 forwarded from the TE (Terminal Equipment) to the MT (Mobile Terminal). The 

trigger may be, e.g., a call set up message including the requested logical channels and 
characteristics. 

At step 402, an Activate PDP Context Request message is forwarded to the 
SGSN. In response thereto, in step 404, the SGSN creates a Create PDP Context 

1 0 Request message. 

In step 406, the SGSN sends the Create PDP Context Request to the GGSN. 
In response to the Create PDP Context Request received from the SGSN, in step 408, 
the GGSN creates a Create PDP Context Response. In step 410, the GGSN associates 
the Charging Identification parameter with the PDP context. In step 412, both the 

1 5 Create PDP Context Response and the Charging Identification are then returned to the 

SGSN in the Create PDP Context Response message. 

The Charging Id is included in the CDRs created by the GGSN and the SGSN. 
The CDRs are sent to the Charging Gateway Functionality (CGR) for further 
processing. From the Charging Gateway Functionality, the CDRs are sent to the 

20 Billing System. This is true for all the embodiments. In addition, it is important that 

the CSCF adds the Charging Id to the CDRs that it creates for the call in question. 
The CSCF sends CDRs either to the Charging Gateway Functionality (CGF) or to the 
Billing System. This way, when creating a bill for a subscriber, the PDP context(s) 
that were used for a specific call can be checked. The Charging Identification in all 

25 those CDRs is the same. 

If the Charging Characteristics change during an active PDP context, the 
SGSN includes the new Charging Characteristics of the PDP context in an Update 
PDP Context Request message, which the SGSN sends to the GGSN. 



BNSDOCID: <WO 0191446A2_I_> 



WO 01/91446 



PCT/IB01/00890 



According to this arrangement of the second embodiment, the Charging Id 
parameter, possibly together with other information (e.g., IMSI, MSISDN, PDP 
address, UE port number from the TFT, Charging Characteristics etc.), is sent from 
the SGSN directly to the CSCF in step 414. This is done either autonomously (in a 
first case) or based on a request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the SGSN sends 
a message including the Charging Id and possibly other information (see above) to the 
CSCF. The message sent by the SGSN may be acknowledged by the CSCF. 

The SGSN must know the CSCF address. The CSCF address may be 
requested from the HSS or may be derived from the TFT which the UE specifies for 
the PDP context which is used for the communication with the CSCF. 

In the second case, at call set up, the CSCF requests information from the 
SGSN. The request is based, e.g., on IMSI or MSISDN. The SGSN sends the 
Charging Id and possibly other information (see above) to the CSCF. 

The CSCF must know the SGSN address. The SGSN address may be 
requested from the HSS. 

The CSCF, in turn, forwards the call set up message to the remote end point in 
step 416. The remote end point then forwards a response message back to the CSCF 
in step 418. The CSCF then forwards the response message to the UE in step 420. 

FIG. 5 illustrates another arrangement of the second embodiment of the 
invention in which the GGSN sends the Charging Identification directly to the CSCF. 
Referring to FIG. 5, a process of sending a charging identification in accordance with 
the present invention begins at step 500 in which a trigger is forwarded from the TE to 
the MT (Mobile Terminal). The trigger may be, e.g., a call set up message including 
the requested logical channels and characteristics. 

At step 502, an Activate PDP Context Request message is forwarded to the 
SGSN. In response thereto, in step 504, the SGSN creates a Create PDP Context 
Request message. In step 506, the SGSN sends the Create PDP Context Request to 
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the GGSN. 

In response to the Create PDP Context Request received from the SGSN, in 
step 508, the GGSN creates a Create PDP Context Response. In step 510, the GGSN 
associates the Charging Identification parameter with the PDP context. In step 512, 
the Create PDP Context Response message including the Charging Identification is 
then returned to the SGSN. 

According to this aspect of the second embodiment, the Charging Id 
parameter, possibly together with other information (e.g., IMSI, MSISDN, PDP 
address, UE port number from the TFT, Charging Characteristics etc.), is sent from 
the GGSN directly to the CSCF in step 514. Step 514 is performed either 
autonomously (in a first case) or based on a request from the CSCF (in a second case). 

In the first case, at PDP context activation (and modification), the GGSN 
sends a message including the Charging Id and possibly other information (see above) 
to the CSCF. The message sent by the GGSN may be acknowledged by the CSCF. 

The GGSN needs to know the CSCF address. The CSCF address may be 
requested from the HSS or may be derived from the TFT which the UE specifies for 
the PDP context that is used for the communication with the CSCF. 

In the second case, at call set up, the CSCF requests information from the 
GGSN. The request is based, e.g., on IMSI or MSISDN. The GGSN sends the 
Charging Id parameter and possibly other information to the CSCF. 

The CSCF forwards the call set up message to the remote end point in step 
5 1 6. The remote end point then forwards a response message back to the CSCF in 
step 5 1 8. The CSCF then forwards the response message to the UE in step 520. 

The second embodiment allows the GPRS and IPT network elements to 
coordinate charging information and other kinds of information, e.g., in order to 
combine charging information collected for a PDP context by the SGSN and the 
GGSN and for a call by the CSCF. Sending the Charging Identification from the 
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SGSN or the GGSN to the CSCF requires an interface between the application layer 
network and the transport layer network. 

Variation of Embodiments 1 and 2 
In a variation of the first and second embodiments, the Charging Identification 
5 generated in the SGSN, GGSN or other network element is a Globally Unique 

Charging Identification (GC1). The GC1 is a combination of the integer value 2a32-1 
(4 bytes) and the ID of the network element which generated it (such as the SGSN or 
GGSN). The length or structure of the network element ID generating the GCI may 
vary according to the specific implementation. It is not necessary that the GCI be 
10 generated in any particular group of network elements. In any circumstance, the 

remaining network elements simply receive and use the GCI generated by the first 
network element. 

After the GCI is generated, it is used during the entire call and the other 
network elements don't generate a charging identification, but instead use the GCI 

1 5 generated by the first network element. The GCI is created and transferred over 

several interfaces in the place of the Charging Identification described above. A 
plurality of separate call detail records (CDRs) can be generated and associated with 
each other using the GCI. For example, the SGSN may create a S-CDR and the 
GGSN may create a G-CDR as explained in 3G TS 32.015. The CSCF (together with 

20 a MGCF) may create a C-CDR. A terminating network (such as a PSTN/MSC) may 

create POC and MTC CDRs. 

When an endpoint (such as a MGCF) receives the GCI passed from the CSCF, 
it may pass it on to another network. Preferably, the GCI can be transferred to, within 
and between 2 nd generation ("2G") networks as well as the 3G network described 

25 above. The SIP and GTP' protocols may be used to carry the GCI in the 3G network 

as described above, and the corresponding protocols in a 2G network may be modified 
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so that they can also carry the GC1. As an example, the connected 2G network may be 
a post-processing system which produces subscriber billing by effectively using the 
GCI to determine and combine charging data for the subscriber in one or more CDRs. 

Embodiment 3 

The subscribers of voice services are accustomed to receiving bills based on 
calls, not based on the transport resources used for making the calls. Subscribers of IP 
telephony often expect similar billing criteria. Consequently, billing for the services 
used (e.g., for the calls) rather than the transport resources used is becoming 
increasingly important. In the case of WAP services, billing for services rather than 
transport resources is already the expectation. 

For an IP telephony call, a PDP context is required to carry the actual voice 
traffic. Both the GPRS/UMTS layer and the IP telephony layer collect charging 
information (CDRs): The GPRS/UMTS layer collects charging information for the 
PDP context while the IP telephony layer collects charging information for the call. A 
common identifier ought to be added to the CDRs to make it possible, for example, to 
bill based only on the CDRs created by the IP telephony layer (i.e., for services) and to 
omit the CDRs created by the GPRS/UMTS layer (i.e., for transport resources). 

A common identifier is needed in the CDRs created by the GPRS/UMTS layer 
and by the IP telephony layer to make it possible to omit certain CDRs and enable 
billing based on services rather than use of transport resources. More specifically, in 
many cases it would be advantageous to selectively omit CDRs created by the 
GPRS/UMTS layer or CDRs created by the IP telephony layer. If that were possible, 
the billing would be operator-specific, in that the operator could decide how to bill the 
subscribers (how to use the created CDRs). 

According to the principles of the invention, a common identifier is associated 
with the CDRs created by the GPRS/UMTS layer and by the IP telephony layer. The 
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common identifier enables charging coordination and other kinds of information 
coordination. 

Instead of using a GGSN-allocated Charging Identification, a call in SIP is 
identified with a Call Identification, which is used as a charging coordinator. The Call 
Identification is allocated by the caller and included in the SIP messages. The MS 
sends the SIP messages to the called party via the CSCF. The CSCF intercepts the 
SIP messages and can thereby obtain the Call Identification from the SIP messages. 

To use the Call Identification for charging coordination or other kinds of 
coordination in accordance with the principles of the invention, the MS sends the Call 
Identification to the SGSN and the GGSN during PDP context activation. More 
specifically, the MS sends the Call Identification to the SGSN along with the Activate 
(Secondary) PDP Context Request message, and the SGSN forwards the Call 
Identification to the GGSN along with the Create PDP Context Request message. 

FIG. 6 illustrates a process for coordinating charging in accordance with a 
third embodiment of the invention, which advantageously enhances coordination of 
information between transport and application layers. As illustrated in FIG. 6, the 
technique in accordance with the present invention begins at the application layer at 
step 600 in which a trigger is forwarded from the TE (Terminal Equipment) to the MT 
(Mobile Terminal). The trigger may be, e.g., a call set up indication including the 
requested logical channels and characteristics, sent from the TE to the MT to start 
PDP context activation. In step 602, the MS initiates a transaction in the form of a 
call. In step 604, the MS assigns a call identification to the call. The process 
described herein works for mobile-originated calls (where the MS allocates the Call 
Identification), as described subsequently with respect to FIG. 7, and also for mobile- 
terminated calls (where the MS receives the Call Identification in the SIP Invite 
message), as described subsequently with respect to FIG. 8. In step 606, the call 
identification is sent from the MS to the CSCF. 
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In step 608, an Activate (Secondary) PDP Context Request message and a Call 
Identification is forwarded from the MS to the SGSN. In step 610, the SGSN sends a 
Radio Access Bearer (RAB) setup message to the UTRAN. In response thereto, in 
step 612, the SGSN creates a Create PDP Context Request message and forwards it to 
the GGSN along with the Call Identification. In response to the Create PDP Context 
Request forwarded by the SGSN, in step 614, the GGSN creates a Create PDP 
Context Response message. 

In step 616, the Create PDP Context Response message is forwarded to the 
SGSN. In response to the PDP Context Response forwarded by the GGSN to the 
SGSN, in step 618, the SGSN forwards an Activate (Secondary) PDP Context Accept 
message to the MS. 

According to the process described herein, the SGSN and the GGSN add the 
Call Identification to the CDRs that they create for the PDP context, and the CSCF 
adds the Call Identification to the CDRs that it creates for the call. 

Accordingly, an operator is given greater flexibility in deciding how to bill 
subscribers for the created CDRs. The operator can selectively omit billing for CDRs 
created by the GPRS/UMTS layer while choosing to bill for CDRs created by the IP 
telephony layer. 

FIG. 7 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with an arrangement of the third embodiment 
of the invention. To enable charging coordination or other kinds of information 
coordination for a mobile-originated call, the Call Id is sent to the CSCF at call set up 
and to the SGSN and to the GGSN at PDP context activation. With reference to FIG. 
7, at 700, the MS allocates a Call Id and sends it to the CSCF in the SIP Invite 
message. At 702, the MS activates at least one PDP context for the call. The MS 
sends the Call Id to the SGSN in the Activate (Secondary) PDP Context Request 
message. If multiple PDP contexts are activated for the call, the MS has to send the 
Call Id to the SGSN at every PDP context activation. At 704, the radio access bearer 
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setup is performed. At 706, the SGSN sends the Call Id to the GGSN in the Create 
PDP Context Request message. At 708 and 710, the (secondary) PDP context 
activation is accepted. 

FIG. 8 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with another arrangement of the third 
embodiment of the invention. FIG. 8 presents an example of charging coordination 
for a mobile-terminated call. With reference to FIG. 8, at 800 the MS receives the SIP 
Invite message. The caller has allocated the Call Id for the call. At 802, the MS 
activates at least one PDP context for the call. The MS sends the Call Id to the SGSN 
in the Activate (Secondary) PDP Context Request message. If multiple PDP contexts 
are activated for the call, the MS has to send the Call Id to the SGSN at every PDP 
context activation. At 804, the radio access bearer setup is performed. At 806, the 
SGSN sends the Call Id to the GGSN in the Create PDP Context Request message. 
At 808 and 810, the (secondary) PDP context activation is accepted. 

Embodiment 4 

In another embodiment similar to Embodiment 3 described above, the 
common identifier associated with the CDRs created by the GPRS/UMTS layer and 
by the IP telephony layer is a tuple or tuple pair used to differentiate connections in IP 
networking. A ''tuple" consists of the IP address and UDP port values related to the 
RTP data flow of the connection. A "tuple pair" consists of the tuples for both the 
source and destination side connection endpoints. To use the tuple or tuple pair for 
charging coordination or other kinds of information coordination in accordance with 
the principles of the invention, the MS sends them to the SGSN and the GGSN during 
PDP context activation. More specifically, the MS sends them to the SGSN along 
with the Activate (Secondary) PDP Context Request message, and the SGSN forwards 
them to the GGSN along with the Create PDP Context Request message. 
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The process for coordinating charging in accordance with this fourth 
embodiment of the invention is illustrated in FIG. 9. At step 900, a trigger is 
forwarded from the TE (Terminal Equipment) to the MT (Mobile Terminal). The 
trigger may be, e.g., a call set up indication including the requested logical channels 
and characteristics, sent from the TE to the MT to start PDP context activation. In 
step 902, the MS initiates a transaction in the form of a call. In step 904, the MS 
assigns the tuple for each proposed media flow it suggests to use within the call. This 
information will then be carried in the SDP part of SIP INVITE and be used as 
destination tuple by the remote endpoint, if the remote endpoint agrees to use the 
proposed media. The process described herein works for mobile-originated calls 
(where the MS allocates the UDP/IP tuple values), as described subsequently with 
respect to FIG. 9, and also for mobile-terminated calls (where the MS receives the 
tuple in the SIP INVITE message), as described subsequently with respect to FIG. 9. 
In step 906, the tuple is sent from the MS to the CSCF. 

In step 908, the media negotiation has traversed the necessary round-trips 
through the CSCF signalling chain and the terminating MS knows at least the initially 
agreed destination and source connection tuples (a tuple pair) for each media flow. 
Preferably, the P-CSCF of both the originating and terminating terminals parse and 
grab the tuple pair values from passing SIP messages (for media authorization and 
policy control purposes). An Activate (Secondary) PDP Context Request message 
and the connection specific tuple pair information is forwarded from the MS to the 
SGSN. In step 910, the SGSN sends a Radio Access Bearer (RAB) setup message to 
the UTRAN. In response thereto, in step 912, the SGSN creates a Create PDP 
Context Request message and forwards it to the GGSN along with the tuple pair. In 
response to the Create PDP Context Request forwarded by the SGSN, in step 914, the 
GGSN creates a Create PDP Context Response message. 

In step 916, the Create PDP Context Response message is forwarded to the 
SGSN. In response to the PDP Context Response forwarded by the GGSN to the 
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SGSN, in step 918, the SGSN forwards an Activate (Secondary) PDP Context Accept 
message to the MS. 

According to the process described herein, the SGSN and the GGSN add the 
tuple pair to the CDRs that they create for the PDP context, and the CSCF adds the 
tuple pair present in media specific part (e.g., SDP) of SIP signalling to the CDRs that 
it creates for the call. 

Accordingly, an operator is given greater flexibility in deciding how to bill 
subscribers for the created CDRs. The operator can selectively omit billing for CDRs 
created by the GPRS/UMTS layer while choosing to bill for CDRs created by the IP 
telephony layer. 

FIG. 10 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with an arrangement of the fourth embodiment 
of the invention. To enable charging coordination or other kinds of information 
coordination for a mobile-originated call, the tuple or tuple pair is sent to the CSCF at 
call set up and to the SGSN and to the GGSN at PDP context activation. With 
reference to FIG. 10, at 1000, the MS allocates a tuple for each proposed media flow it 
suggests to use within the call. This information will then be carried in a media 
specific (e.g., SDP) part of SIP INVITE and be used as destination tuple by the remote 
endpoint, if it agrees to use the proposed media. MS sends the tuples for each 
proposed media flow to the CSCF in the SIP INVITE message. Prior to this 
signalling, the MS activates at least one (signalling) PDP context for the call if one is 
not already activated. After the media negotiation has traversed the necessary round- 
trips through the CSCF signalling chain and both originating and terminating terminal 
know the at least initially agreed destination and source connection tuples (a tuple 
pair) for each media flow, the MS sends the connection specific tuple pair to the 
SGSN in the Activate (Secondary) PDP Context Request message. If multiple PDP 
contexts (multiple media) are activated for the call, the MS has to send the tuple pair 
assigned to the particular media flow to the SGSN at every PDP context activation. 
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At 1 004, the radio access bearer setup is performed. At 1 006, the SGSN sends the 
tuple pair to the GGSN in the Create PDP Context Request message. At 1008 and 
1010, the (secondary) PDP context activation is accepted. 

FIG. 1 1 is a signaling flow diagram illustrating coordination of the application 
layer and transport layer in accordance with another arrangement of the fourth 
embodiment of the invention. FIG. 1 1 presents an example of charging coordination 
or other kinds of information coordination for a mobile-terminated call. With 
reference to FIG. 1 1 , at 1 100 the MS receives the SIP INVITE message. The caller 
has allocated the destination tuple values for each intended original or dynamically 
added media component for the call. At 1 102, the MS activates at least one secondary 
PDP context for the call. The MS sends the tuple or tuple pair to the SGSN in the 
Activate (Secondary) PDP Context Request message. If multiple PDP contexts are 
activated for the call, the MS has to send the tuple or tuple pair to the SGSN at every 
PDP context activation. At 1 104, the radio access bearer setup is performed. At 
1 106, the SGSN sends the tuple pair to the GGSN in the Create PDP Context Request 
message. At 11 08 and 1110, the (secondary) PDP context activation is accepted. 

The use of the tuple pairs in the fourth embodiment simplifies the terminal 
inter-layer (application layer - GPRS/UMTS layer) processing and can be used 
effectively regardless of whether the MS is a TE + MT combination or a unified UE. 
This is because the connection specific UDP and TCP port information is sent 
automatically without need for specific MT interception/parsing process of SIP 
messages from TE (as in the third embodiment) or adding an extra message (charging 
ID received from SGSN) to TE-originated SIP messages. The port information is sent 
to both CSCF in SDP part of SIP INVITE or ACK message at application layer and to 
SGSN & GGSN in the TFT information of PDP Context Activation Request message 
(The tuple pair included to each PDP context's TFT needs to be forwarded to the 
MT's GPRS session management layer - this can e.g. be done via MT's 
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implementation specific bearer management or QoS application programming 
interface (API)). 

As a variation of the fourth embodiment, in the CSCF-GGSN interface end, 
the tuple pairscan be used as the key identifiers to which the charging ID (and policing 
authorization) is assigned or linked to, although the charging ID would be used for the 
identifier in CGR and billing. A call is triggered over the primary (signalling) PDP 
context by sending a call setup (in SIP: INVITE) message with logical channel 
information for the receiver side (i.e., the ports to which it is ready to receive real-time 
data. The CSCF receives the INVITE with SDP (with coded bandwidth and port 
information) and stores the information. The signalling is sent to the remote end, 
which is answered (e.g., SIP 183 message) and the CSCF now receives a new set of 
SDP information with codec, bandwidth and terminating side destination ports 
provided by the remote end SDP. CSCF executed examination ofthe codec type data 
received from SIP messages from both terminals results in an agreed codec set, whose 
destination [IP address, port] tuple values are known for each IP connection CSCF 
should authorise. 

The CSCF can use the CSCF-PCF-GGSN interfaces (or CSCF-GGSN if PCF 
is integrated to CSCF) to request policy control actions (bandwidth authorization) and 
charging coordination between layers with the tuplesas keys. The GGSN admits the 
bandwidth and later during the secondary PDP context activation process, assigns the 
charging ID to the created PDP context associated with the key tuple values, and 
forwards the charging ID back to the CSCF for charging coordination purposes. The 
CSCF doesn't need to parse the Charging-ID from received SIP messages - there is no 
risk of malicious MT since it won't be intercepting or modifying any SIP messages 
received from a TE. Instead it can correlate the charging ID sent by GGSN to the port 
information. 

The charging flexibility offered for the operator is further improved in the 
fourth embodiment if the TE sends a RE-INVITE message with changed QoS/codec 
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information, since the CSCF will notice outcome of the dynamic change in the 
resulting signalling, and request new authorization and get a new charging ID. 
Furthermore, a new charging ID will be created to charging records for each new 
dynamically added real-time PDP context/media flow. If the real-time flows are to 
utilise RTP/UDP/IP header compression at the PDP layer, each media flow needs its 
own PDP context. Thus, operator charging can, if desired, follow the media changes 
(audio to videotelephony back to audio,. . .) within an end-to-end call. Following the 
process described in the third embodiment of this invention, the Call-ID would not 
change and would not indicate the media specific connection details in the charging 
information if, for example, SGSN and GGSN CDRs are omitted by an operator 
decision. 

It is to be noted that in the description of the invention above, numerous 
details known to those skilled in the art have been omitted for the sake of brevity. 
Such details are readily available in numerous publications including the previously 
cited protocols. 

Although the present invention has been described with reference to a number 
of illustrative embodiments, it should be understood that numerous other 
modifications and embodiments can be devised by those skilled the art which will fall 
within the spirit and scope of the principles of this invention. More particularly, 
reasonable variations and modifications are possible in the component parts and/or 
arrangements of the subject combination arrangement within the scope of the 
foregoing disclosure, the drawings, and the appended claims without departing from 
the spirit of the invention. In addition to variations and modifications in the 
component parts and/or arrangements, alternative uses will also be apparent to those 
skilled the art. 
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WHAT IS CLAIMED IS: 

1 . A method for coordinating charging information in a communications 
network, the method comprising: 

establishing a communication channel; 

associating a charging identification with said communication channel; and 
sending said charging identification from a first network element in the 
transport layer to a second network element in the application layer. 

2. The method of claim 1 , wherein said second network element adds said 
charging identification to charging information which said second network element 
collects, 

3. The method of claim 1, wherein said first network element sends an 
address of a network element together with said charging identification to said second 
network element. 

4. The method of claim 3, wherein said second network element adds said 
address of a network element to charging information which said second network 
element collects. 

5. The method of claim 1 or 3, wherein said first network element sends 
security information together with said charging identification to said second network 
element. 

6. The method of claim 5, wherein said second network element verifies said 
charging identification against said security information. 

7. The method of claim 1, wherein said communication channel is a Packet 
Data Protocol (PDP) context. 

8. The method of claim I, wherein said charging identification is a GGSN 
allocated Charging Id. 

9. The method of claim 1, wherein said first network element is a Mobile 
Station (MS). 
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10. The method of claim 1, wherein said first network element is a Serving 
GPRS Support Node (SGSN). 

1 1 . The method of claim I , wherein said first network element is a Gateway 
GPRS Support Node (GGSN). 

1 2. The method of claim 1, wherein said second network element is a Call 
State Control Function (CSCF). 

1 3. The method of claim 9 or 1 2, wherein an SGSN sends said address of a 
network element to said first network element. 

14. The method of claim 9, 10, 1 1 or 12, wherein said address of a network 
element is an address of a GGSN. 

1 5. The method of claim 1 , wherein said transport layer is a GPRS/UMTS. 

1 6. The method of claim 1 , wherein said transport layer is a Packet Switched 
Core Network domain. 

1 7. The method of claim 1 , wherein said application layer is a IP Multimedia 
Core Network domain. 

1 8. The method of claim 1 , wherein said communication network is a packet 
switched wireless network. 

1 9. The method of claim 1 , wherein 

sending said charging identification is performed autonomously. 

20. The method of claim 1 , wherein 

sending said charging identification is performed based on a request from said 
second network element. 

21. The method of claim 1, wherein said second network element sends said 
charging identification towards an endpoint of a communication. 
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22. The method of claim 21, wherein said second network element sends security 
information together with said charging identification toward said endpoint of a 
communication. 

23. The method of claim 21, wherein said second network element sends an 
address of a network element together with said charging identification to said endpoint 
of a communication. 

24. The method of claim 9, wherein said second network element adds an address 
of said first network element to charging information which said second network element 
collects. 

25. A method for coordinating information between a transport layer and an 
application layer in a communications network, the method comprising: 

initiating a transaction in said application layer of a first network element; 
assigning an identification to said transaction; 

initiating a communication channel in said transport layer of said first network 
element; and 

associating said communication channel with said transaction using said 
identification. 

26. The method of claim 25, wherein said identification is forwarded to a second 
network element in said application layer. 

27. The method of claim 26, wherein said identification is forwarded to a third 
network element and a fourth network element in a transport layer. 

28. The method of claim 27, wherein charging information generated by said 
fourth network element and said third network element in said transport layer and by the 
second network element in said application layer is associated with said identification. 
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29. The method of claim 25, wherein said identification is a call identification of 
a SIP message. 

30. The method of claim 26, wherein said second network element is a CSCF. 

31. The method of claim 27, wherein said third network element is a SGSN and 
said fourth network element is a GGSN. 

32. The method of claim 28, wherein said charging information is a CDR. 

33. The method of claim 25, wherein said communication channel is a Packet 
Data Protocol (PDP) context. 

34. The method of claim 25, wherein said transaction is a call. 

35. A system for coordinating information between an application layer and a 
transport layer in a communication network, the system comprising: 

means for initiating a transaction in said application layer of a first network 
element; 

means for assigning an identification to said transaction; 

means for initiating a communication channel in said transport layer of said first 
network element; and 

means for associating said communication channel with said transaction using 
said identification. 

36. A method for coordinating charging information in a communications 
network, the method comprising: 

establishing a communication connection; 

generating a globally unique charging identification in a first network element and 
associating said globally unique charging identification with said communication 
connection; and 
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sending said globally unique charging identification from said first network 
element to a second network element. 

37. The method of claim 36, wherein said second network element uses said 
globally unique charging identification to collect charging information. 

38. The method of claim 36, wherein said globally unique charging identification 
includes the address of the first network element. 

39. The method of claim 36, wherein said communication channel is a Packet 
Data Protocol (PDP) context. 

40. The method of claim 36, wherein said globally unique charging 
identification is generated by a GGSN. 

41 . The method of claim 36, wherein said first network element is a Mobile 
Station (MS). 

42. The method of claim 36, wherein said first network element is a Serving 
GPRS Support Node (SGSN). 

43. The method of claim 36, wherein said first network element is a Gateway 
GPRS Support Node (GGSN). 

44. The method of claim 36, wherein said second network element is a Call State 
Control Function (CSCF). 

45. The method of claim 36, wherein said second network element sends said 
globally unique charging identification towards an endpoint of a communication. 

46. The method of claim 45, wherein said second network element sends said 
globally unique charging identification to a second network. 

47. The method of claim 45, wherein said second network collects charging 
data using said globally unique charging identification and prepares billing using the 
collected charging data. 
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48. the method of claim 47, wherein said second network collects 
charging data from a plurality of call detail records associated with said globally 
unique charging identification. 

49. A method for coordinating information between a transport layer and 
an application layer in a communications network, the method comprising: 

initiating a transaction in said application layer of a first network element; 
assigning a tuple or tuple pair for each communication connection within said 
transaction; 

initiating at least one communication connection in said transport layer of said 
first network element; and 

associating said at least one communication connection with said transaction 
using said tuple or tuple pair. 

50. The method of claim 49, wherein said tuple or tuple pair is forwarded to a 
second network element in said application layer. 

51. The method of claim 50, wherein said tuple or tuple pair is forwarded to a 
third network element and a fourth network element in a transport layer. 

52. The method of claim 51, wherein charging information generated by said 
fourth network element and said third network element in said transport layer and by 
the second network element in said application layer is associated with said tuple or 
tuple pair. 

53. The method of claim 49, wherein said tuple includes a destination IP 
address and port information of a transaction specific media connection. 

54. The method of claim 50, wherein said second network element is a CSCF. 

55. The method of claim 51, wherein said third network element is a SGSN 
and said fourth network element is a GGSN. 
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56. The method of claim 52, wherein said charging information is a CDR. 

57. The method of claim 49, wherein said communication connection is a Packet 
Data Protocol (PDP) context. 

58. The method of claim 49, wherein said transaction is a call. 

59. A system for coordinating information between an application layer and a 
transport layer in a communications network, the system comprising: 

means for initiating a transaction in said application layer of a first network 
element; 

means for assigning a tuple or tuple pair to said transaction; 

means for initiating at least one communication connection in said transport layer 
of said first network element; and 

means for associating said at least one communication connection with said 
transaction using said tuple or tuple pair. 



34 



BNSDOCID: <WO 0191446A2J_> 



WO 01/91446 PCT/IBOl/00890 

1/11 



FIG. 1 



SEND AN ACTIVATE PDP CONTEXT REQUEST FROM THE 
MT TO THE SGSN 



100 



102 



SEND A RAB SET UP MESSAGE TO THE UTRAN / 
GERAN 



104 



SEND A CREATE PDP CONTEXT REQUEST MESSAGE 
FROM THE SGSN TO THE GGSN 



CREATE THE PDP CONTEXT AND RETURN A CREATE 
PDP CONTEXT RESPONSE TO THE SGSN 



•106 



-108 



SEND AN ACTIVATE PDP CONTEXT ACCEPT MESSAGE 
FROM THE SGSN TO THE MT 



BNSDOCID: <WO 0191446A2_I_> 



WO 01/91446 



2/11 



PCT/IB01/00890 




BNSDOCID: <WO 0191446A2J_> 



WO 01/91446 



3/11 



PCT/IBOl/00890 



FIG. 3 



FORWARD TRIGGER TO THE MT 



FORWARD AN ACTIVATE PDP CONTEXT REQUEST TO THE 
SGSN 



FORWARD A CREATE PDP CONTEXT REQUEST MESSAGE 
FROM THE SGSN TO THE GGSN 

i 



CREATE A CREATE PDP CONTEXT RESPONSE MESSAGE 



ASSOCIATE A CHARGING IDENTIFICTION PARAMETER 
WITH THE CREATE PDP CONTEXT RESPONSE 



FORWARD THE CREATE PDP CONTEXT RESPONSE 
INCLUDING THE CHARGING IDENTIFICATION PARAMETER 
FROM THE GGSN TO THE SGSN 



FORWARD AN ACTIVATE PDP CONTEXT ACCEPT 
MESSAGE THAT INCLUDES THE CHARGING 
IDENTIFICATION PARAMETER AND THE GGSN ADDRESS 



300 



302 



304 



306 



308 



310 



312 



FORWARD THE SET UP MESSAGE THAT INCLUDES THE 
CHARGING IDENTIFICATION AND THE GGSN ADDRESS 
FROM THE MT TO THE CSCF 



314 



FORWARD THE SET UP MESSAGE THAT INCLUDES THE 
CHARGING IDENTIFICATION AND THE GGSN ADDRESS TO 
THE REMOTE END POINT 



316 



FORWARD THE CONNECT MESSAGE TO THE CSCF 



318 



320 



FORWARD THE CONNECT MESSAGE TO THE MT 



r 



0191446A2 I > 



* WO 01/91446 



4/11 



PCT/IB01/00890 



FIG. 4 

FORWARD TRIGGER TO THE MT 



FORWARD AN ACTIVATE PDP CONTEXT REQUEST TO 
THE SGSN 

i 

CREATE A CREATE PDP CONTEXT REQUEST MESSAGE 



SEND THE CREATE PDP CONTEXT REQUEST MESSAGE 
FROM THE SGSN TO THE GGSN 

I 

CREATE A CREATE PDP CONTEXT RESPONSE 



ASSOCIATE A CHARGING IDENTIFICATION PARAMETER 
WITH THE CREATE PDP CONTEXT RESPONSE 

I 

FORWARD THE CREATE PDP CONTEXT RESPONSE 
INCLUDING THE CHARGING IDENTIFICATION 



V 



V 



V 



V 



V 



400 



402 



404 



406 



408 



i -410 



V 



412 



414 



FORWARD THE CHARGING IDENTIFICATION AND THE 
GGSN ADDRESS FROM THE SGSN TO THE CSCF 

i 

FORWARD THE SET UP INDICATION THAT INCLUDES THE V 416 
CHARGING IDENTIFICATION AND THE GGSN ADDRESS 
FROM THE CSCF TO THE REMOTE END POINT 



418 



FORWARD THE CONNECT INDICATION TO THE CSCF 
FORWARD THE CONNECT INDICATION TO THE MT |/" 420 



WO 01/91446 



5/11 



PCT/IB01/00890 



FIG. 5 

FORWARD TRIGGER TO THE MT 



FORWARD AN ACTIVATE PDP CONTEXT REQUEST TO 
THE SGSN 



CREATE A CREATE PDP CONTEXT MESSAGE 



J. 



SEND THE CREATE PDP CONTEXT REQUEST MESSAGE 
TO THE GGSN 



CREATE A CREATE PDP CONTEXT RESPONSE 



ASSOCIATE A CHARGING IDENTIFICATION PARAMETER 
WITH THE CREATE PDP CONTEXT RESPONSE 



RETURN THE CREATE PDP CONTEXT RESPONSE 
INCLUDING THE CHARGING IDENTIFICATION 
PARAMETER FROM THE GGSN TO THE SGSN 



SEND THE CHARGING IDENTIFICATION AND THE GGSN 
ADDRESS FROM THE GGSN TO THE CSCF 



500 



502 



504 



506 



508 



+ -510 



512 



514 



FORWARD THE SET UP INDICATION THAT INCLUDES THE V 516 
CHARGINGJD AND THE GGSN ADDRESS FROM THE 
CSCF TO THE REMOTE END POINT 



FORWARD THE CONNECT INDICATION TO THE CSCF ~Y 51 8 

T 



FORWARD THE CONNECT INDICATION TO THE MT )f 



520 



_0191446A2_I_> 



« WO 01/91446 



6/11 



PCT/IBO 1/00890 



FIG. 6 



FORWARD TRIGGER TO THE MT 



INITIATE A TRANSACTION IN THE FORM OF A CALL 



ASSIGN A CALL IDENTIFICATION TO THE CALL 



SEND THE CALL IDENTIFICATION FROM THE MS TO THE 
CSCF 



FORWARD AN ACTIVATE PDP CONTEXT REQUEST AND 
THE CALL IDENTIFICATION FROM THE MS TO THE SGSN 



SEND A RAB SETUP MESSAGE TO THE UTRAN/GERAN 



FORWARD A CREATE PDP CONTEXT REQUEST MESSAGE 
AND THE CALL IDENTIFICATION FROM THE SGSN TO THE 



J. 



CREATE A CREATE PDP CONTEXT RESPONSE MESSAGE 



FORWARD THE CREATE PDP CONTEXT RESPONSE FROM 
THE GGSN TO THE SGSN 



600 



602 



604 



606 



608 



610 



612 



614 



616 



FORWARD AN ACTIVATE PDP CONTEXT ACCEPT 
MESSAGE FROM THE SGSN TO THE MS 



618 



BNSDOCID: <WO 0191446A2_I_> 



WO 01/91446 PCT/IB01/00890 

7/11 




BNSDOCIO: <WO 0191446A2_I_> 



WO 01/91446 



PCT/1B01/00890 



8/11 



O 
CO 

o 



CO 
CD 
CD 



CO 
CD 
CO 



DC 



CO 



O 

CD 



CO 

o 

CO 



03 

O 



co 

CD 

cr 

CD 

DC 

CD 



CD 
C/> 

O 

co 

CD 

DC 

>< 

CD 



CO 

O 



CO 
CD 
=3 
or 

- CD 
DC' 

*>< 
a> 

o 
O 

Q- 
Q 
Q. 

2? 

CO 

- c 
o 
o 

CD 

c£ 

aj 

*c5 
_> 

o 
<C 

c\T 

o 

oo 



o 
O 

Q_ 
Q 
CL 

a> 

c5 
a> 

O 

CD^ 

o 
oo 



T 



o 
O 

Q_ 
Q 
Q_ 

& 

a> 

O 

oo 
o 

CO 



CD 
CO 

a5 

CO 
CD 
"CO- 
CO 

CO 
CD 

o 
o 

<c 
o 

co 
DC 

o 



CD 
. O. 

o 

<c 

>< 

CD 



O 

O 
a. 
Q 

Q- 
CO 

- c* 
o 
o 

CD 
CO 

CD 

| 

<£ 



BNSDOCID: <WO 0191446A2_I_> 



WO 01/91446 



9/11 



PCT/IBOl/00890 



FIG. 9 

FORWARD TRIGGER TO THE MT 



^900 

j x-902 



INITIATE A TRANSACTION IN THE FORM OF A CALL 



ASSIGN A TUPLE PAIR TO THE CALL 



SEND THE TUPLE PAIR FROM THE MS TO THE CSCF 



FORWARD AN ACTIVATE PDP CONTEXT REQUEST AND 
THE TUPLE PAIR FROM THE MS TO THE SGSN 



SEND A RAB SETUP MESSAGE TO THE UTRAN/GERAN 



FORWARD A CREATE PDP CONTEXT REQUEST MESSAGE 
AND THE TUPLE PAIR FROM THE SGSN TO THE GGSN 



CREATE A CREATE PDP CONTEXT RESPONSE MESSAGE 



FORWARD THE CREATE PDP CONTEXT RESPONSE FROM 
THE GGSN TO THE SGSN 



904 



906 



908 



910 



912 



914 



916 



FORWARD AN ACTIVATE PDP CONTEXT ACCEPT 
MESSAGE FROM THE SGSN TO THE MS 



918 



VO 0191446A2_I_> 



WO 01/91446 



PCT/IB01/00890 



10/11 




BNSDOCID: <WO 0191446A2_I_> 



WO 01/91446 PCT/IB01/00890 

11/11 



O 
CO 
O 



eo 
Q_ 
CD 
Q. 



CO 
CD 
CD 



CO 
CO 



DC 



CO 
Q. 

jCD 



CO 



CD 

"> 

CO 
o 



CO 
CD 

O" 

<D 

DC 

>< 

CD 



CD 
CO 

O 
O- 
CO 
<D 

DC 

>< 

CD 



CO 
_CD 



CO 
CD 
Z3 

cr 

CD 
"DC 



O 
Ql 
Q 
CL 

CD 

ca 

CD 
O 

o 



x 
a> 

o 
O 

O- 
Q 

QU 

£? 

CO 
X5 



* O 

o 

CD 
CO 

CD 

| 
<c 

c\T 
o 



-O 

o 

Q- 
Q 
Q_ 

CD 

a5 
cd 

O 

cxT 
o 



CD 
CO 

CD 

CO 
CD 
_DQ 

CO 
CO 
CD 
O 
O 
<£ 

o 

CO 

DC 



cx 

CD 
O 
O 

">< 

CD 



Q 

CO 



- o 
o 

CD 
CO 

a> 

CO 

o 



BNSDOCIO: <WO 0191446A2_I_> 



(12) INTERNATIONAL APPLICATION PUBLISHED UNDER THE PATENT COOPERATION TREATY (PCT) 



(19) World Intellectual Property Organization 

International Bureau 

(43) International Publication Date 
29 November 2001 (29.11.2001) 




PCT 



(10) International Publication Number 

WO 01/091446 A3 



(51) International Patent Classification 7 : 

I I04L 12/14, 29/06 



(21) International Application Number: PCT/IB01/00890 

(22) International Filing Date: 21 May 2001 (21.05.2001) 

(25) Filing Language: English 

(26) Publication Language: 



H04M 15/00, 4 D 49, FIN-02660 Espoo (FT). BERTENYI, Balazs; 6. 

Nagyszalonta, H-118 Budapest (HU). IVANOV, Nedko; 
16 Harang Street, H-1033 Budapest (HU). HONKO, 
Harri; Tuomiokirkonkatu 38 C 17, FIN-33100 Tampere 
(FI). KOSKINEN, Juha-Pekka; Heinajoenkatu 13, 
FTN-13210 Hameenlinna (FI). VALLINEN, Juha; Lento- 
kentantie 26, FIN-33900 Tampere (FI). HOPEAHARJU, 
Merja; Halimajarventi 32, FTN-36100 Kangasala (FI). 



(30) Priority Data: 

09/577,152 
09/636,738 
09/758,267 



English (74) Agents: BRUNDIDGE, Carl, I. et al.; Antonelli, Terry, 
Stout & Kraus, LLP, Suite 1800, 1300 N. Seventeenth 
Street, Arlington, VA 22209 (US). 



24 May 2000 (24.05.2000) US 

1 1 August 2000 ( 1 1 .08.2000) US 

12 January 2001 (12.01.2001) US 



(71) Applicant: NOKIA CORPORATION [FI/FI], Keilalah 
dcntic 4, FIN-02150 Espoo (FI). 



(81) Designated States (national): CN, JP, LC. 

(84) Designated States (regional): European patent (AT, BE, 
CH, CY, DE, DK, ES, FI, FR, GB, GR, IE, IT, LU, MC, 
NL, PT, SE, TR). 



(71) Applicant (for LC only): NOKIA INC. [US/US]; 6000 Published: 



Connection Drive, Irving, TX 75039 (US). 



— with international search report 



(72) Inventors: FACCIN, Stefano; 3421 Dartmoor Drive, 
Dallas, TX 75229 (US). HURTTA, Tuija; Kiskottajankuji 



(88) Date of publication of the international search report: 

13 March 2003 

[Continued on next page] 



(54) Title: COMMON CHARGING IDENTIFIER FOR COMMUNICATION NETWORKS 




BSS/ 

(TEH -rMfV HGERAN 
R Urn 



R Uu 





****** 

\-j-Gt 
1SGSW 



ON 



O 



• v \ I Mc J / 

SIGNALLING INTERFACE " 1 MSC SERVER~| -H -i-^ jGMSC SERVER! - IT-SOW*) | 

SIGNALLING AND DATA ? 1 ^ - - / 



TRANSFER INTERFACE 




Mh 

(57) Abstract: In a first embodiment of the invention, when an Activate PDP Context Request message is forwarded to a Service 
GPRS Support Node (SGSN), the SGSN creates a Create PDP Context Request message and forwards it to a Gateway GPRS Support 
Node (GGSN). In response to the Create PDP Context Request forwarded by the SGSN, the GGSN creates a Create PDP Context 
Response message. When a PDP context is created by the GGSN, the GGSN associates a Globally Unique Charging Identification 
(GCI) with the PDP context. Then, the Create PDP Context Response including the GO is forwarded to the SGSN. The GCI is sent 
from the SGSN to the UE and from the UE to the CSCF. In a second embodiment of the invention, the GCI is sent from the SGSN or 
the GGSN directly to the Call State Control Function (CSCF). Sending the GCI can be performed either autonomously or based on 
a request from the CSCF. In either embodiment, the CSCF can send the GCI to a second network which performs processing, such 
as billing, from data collected from call detail records associated with the GCI. 



BNSDOCID: <WO 0191446A3J_> 



WO 01/091446 A3 ««B«1II«««MIB 

For two-letter codes and other abbreviations, refer to the "Guid- 
ance Notes on Codes and Abbreviations " appearing at the begin- 
ning of each regular issue of the PCT Gazette. 



BNSDOCID: <WO 0191446A3_I_> 



INTERNATIONAL SEARCH REPORT 



14 onal Application No 

PCT/IB 01/00890 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 H04M15/00 H04L12/14 H04L29/06 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 H04M H04L H04Q 



Documentation searched other than minimum documentation to the extent that such documents are included In the fields searched 



Electronic data base consulted during the international search (name of data base and, where practical, search terms used) 

EPO-Internal , WPI Data, INSPEC 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 0 Citation of document, with Indication, where appropriate, of the relevant passages 



Relevant to claim No. 



WO 95 22230 A (ERICSSON TELEFON AB L M) 

17 August 1995 (1995-08-17) 

abstract 

page 2, line 15 -page 11, line 18; claims 
1-50; figures 1-5 

WO 99 56445 A (HUBBARD ELISABETH ; TELIA AB 
(SE)) 4 November 1999 (1999-11-04) 
the whole document 

WO 99 41928 A (NOKIA TELECOMMUNICATIONS OY 

;PALKIST0 VIRPI (FI)) 

19 August 1999 (1999-08-19) 

abstract 

page 5, line 23 -page 11, line 5; claims 
1-9; figures 1-4 

-/-- 



1-48 



1-48 



25-35, 
49-59 



Further documents are listed in the continuation of box C. 



Patent famliy members are listed in annex. 



° Special categories of cited documents : 

"A" document defining the general state of the art which is not 

considered to be of particular relevance 
•E* earlier document but published on or after the international 

filing date 

•L' document which may throw doubts on priority claim(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O' document referring to an oral disclosure, use, exhibition or 
other means 

•P* document published prior to the international filing date but 
later than the priority date claimed 



T" later document published after the international filing date 
or priority date and not In conflict with the application but 
cited to understand the principle or theory underlying the 
invention 

'X' document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
involve an inventive step when the document Is taken alone 

•Y' document of particular relevance; the claimed Invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of the international search 



11 September 2002 



Date of mailing of the international search report 



17/09/2002 



Name and mailing address of the ISA 

European Patent Office, P.B. 5818 Patentlaan 2 
NL - 2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 
Fax: (+31-70) 340-3016 



Authorized officer 



Todorut, C 



Form PCT/ISA/210 (second sheet) (July 1992) 
BNSDOCID: <WO 0191446A3_I_> 



INTERNATIONAL SEARCH REPORT 



li tonal Application No 

PCT/IB 01/00890 



C.(Contlnuation) DOCUMENTS CONSIDERED TO BE RELEVANT 



Category c 



Citation of document, with indication .where appropriate, of the relevant passages 



Relevant to claim No. 



WO 97 26739 A (NOKIA TELECOMMUNICATIONS 0Y 
;KARI HANNU H (FI); HAEMAELAEINEN JARI) 
24 July 1997 (1997-07-24) 
the whole document 



1-59 



BNSDOCID: <WO. 



Form PCT/lSA/210 (continuation of second sheet) (July 1992) 
0191446A3_I_> 



INTERNATIONAL SEARCH REPORT 

t 

Information on patent family members 



I tlonal Application No 

PCT/IB 01/00890 



» ) 



Patent document 




Publication 




Patent family 




Publication 


cited in search report 




date 




member(s) 




date 


WO 9522230 


A 


17-08-1995 


AU 


/* ~7 A A A 1 

679841 


Pi a 

B2 


10-07-1997 






AU 


1721795 


A 

A 


on aa i ft/\r 

29-08-1995 






CN 


1124556 


A ,B 


lZ-uO-199o 






DE 


/"•/■VP" A A A A A 

69509828 


Dl 


a 1 r\7 i a a, a 

01-07-1999 






DE 


69509828 


*T* A 

T2 


07-10-1999 






DK 


692174 


T3 


15-11-1999 






EP 


0692174 


A "1 

Al 


i "7 a i i c\c\a 

17-01-1996 






EP 


0895398 


A2 


a *■> aa i AAA 

03-02-1999 






ES 


A™\ H **\ AAA /"\ 

2134442 


T3 


#^ -1 «i r\ i a A A 

01-10-1999 






FI 


954659 


A 


OA Art 1 AftC 

29-09-1995 






GR 


3030893 


T3 


A A 11 1 AAA 

30-11-1999 






HK 


1014328 


Al 


13-10-2000 






JP 


9504150 


T 


22-04-1997 






WO 


9522230 


A2 


i *7 no i ftnc 

l/-Uo-lyyb 






SG 


49240 


Al 


*i a Af~ -i aaa 

18-05-1998 






US 


5781855 


A 


1 A A~7 1 AAA 

14-07-1998 


W0 9956445 


A 


04-11-1999 


EE 


200000637 A 


15-04-2002 




EP 


1076977 A2 


21-02-2001 






NO 


20005344 


A 


oo i o onnn 






SE 


9802666 A 


OA 1 A 1 AAA 

29-10-1999 






WO 


9956445 A2 


f\ A 11 1AAA 

04-11-1999 


W0 9941928 


A 


19-08-1999 


FI 


980302 


A 


1 1 a O 1 AAA 

11-08-1999 






AU 


2425699 


A 


30-08-1999 






CN 


1256060 


T 


07-06-2000 






EP 


0980636 Al 


oo no onnn 
£o— U£— £UUU 






WO 


9941928 Al 


1 A AA 1 AAA 

19-08-1999 






JP 


2002507374 T 


Ar* AO OAAA 

05-03-2002 


WO 9726739 


A 


24-07-1997 


FI 


960185 


A 


•% /~ r\ "7 1 AA1 

16-07-1997 






AU 


713041 


B2 


25-11-1999 






AU 


1445897 A 


11-08-1997 






EP 


0875108 Al 


04-11-1998 






WO 


9726739 


Al 


24-07-1997 






JP 


2000503825 


T 


28-03-2000 



Form PCT/ISA/210 (patent family annex) (July 1992) 
BNSDOCID: <WO 0191446A3_I_> 



